fix: sync playback resume position across devices in real-time (#91) - #130

Summary

Closes #91.

Cross-device playback resume position now updates within ~5 seconds of a progress update on another device, instead of waiting for the receiving device to manually reopen Home or for the 5-minute periodic fallback sync.

Reported behavior

If I stop an episode for example at minute 20 and finish it later on device A, device B is still showing the episode to resume at minute 20 instead of starting the next episode.

Root cause

RealtimeSyncManager only subscribed to one Supabase realtime channel: account_sync_state. But playback progress is written directly to a different table — watch_history — by WatchHistoryRepository.saveProgress() every ~10 seconds during playback. The account_sync_state snapshot is only pushed at pause/stop/end, which meant:

• ✓ User finished an episode on device A → pushed via account_sync_state on END → device B realtime pull works.
• ✓ User paused mid-episode on device A → pushed via account_sync_state on PAUSE → works.
• ✗ User actively watching on device A with no pause: watch_history was being updated on Supabase every 10 seconds, but device B had no realtime signal and only saw the new position after manually reopening Home or after the 5-minute periodic fallback fired.

The bug has been invisible for users who always pause or finish episodes cleanly, but has been breaking cross-device experience for anyone switching devices mid-episode.

Fix

1. Second realtime channel for watch_history

Subscribe to a second channel on the same WebSocket listening for INSERT + UPDATE on watch_history filtered by user_id=eq.$userId:

// Channel 2: watch_history INSERT + UPDATE events for cross-device Continue
// Watching refresh. We subscribe to both INSERT (first watch of a new item)
// and UPDATE (position/progress changes) so either event refreshes the other
// device's Home row.
val watchHistoryJoin = JSONObject().apply {
    put("topic", "realtime:watch_history")
    ...
}
ws.send(watchHistoryJoin.toString())

2. Topic-based dispatch in handleMessage

postgres_changes events now route by topic:

• realtime:account_sync → debouncedPull() (full cloud snapshot restore — unchanged)
• realtime:watch_history → debouncedWatchHistoryEmit() (lightweight CW-only refresh — new)

Watch-history events do not trigger cloudSyncRepository.pullFromCloud(). That would be wasteful for a single-row position update — it would re-download the entire addons/profiles/catalogs/IPTV snapshot.

3. watchHistoryEvents: SharedFlow<Unit>

New event stream on RealtimeSyncManager. HomeViewModel collects it in init and calls the existing refreshContinueWatchingOnly(force = true), which re-queries watch_history via WatchHistoryRepository.getContinueWatching() and updates the Continue Watching row inline — no home reload.

4. 5-second debounce to coalesce bursts

Watch history fires every ~10 s during active playback. Without coalescing, a user binge-watching on device A would trigger a Home refresh on every other device every 10 seconds. The new WATCH_HISTORY_DEBOUNCE_MS = 5_000L groups rapid-fire events into a single refresh.

5. Self-echo protection

WatchHistoryRepository.saveProgress() now calls realtimeSyncManager.markLocalWatchHistoryWrite() on every successful save. debouncedWatchHistoryEmit() checks that timestamp with a 3-second window and skips the emit when the event almost certainly came from our own write. Without this, device A would pointlessly refresh its own Continue Watching row every 10 seconds while watching.

private fun debouncedWatchHistoryEmit() {
    if (System.currentTimeMillis() - lastLocalWatchHistoryWriteTimestamp < 3_000L) {
        return  // skip — our own write
    }
    ...
}

6. Periodic fallback: 5 minutes → 90 seconds

PERIODIC_SYNC_INTERVAL_MS was 5 minutes. Lowered to 90 seconds so users on flaky connections (or devices that missed a realtime notification) still see fresh data within a reasonable window. The interval runs pullFromCloud() only if nothing else has fired in between — net cost is at most one small Supabase query per 90 s per active user.

Dependency injection

WatchHistoryRepository now takes Provider<RealtimeSyncManager> (lazy). This matches the existing Provider<AuthRepository> pattern in the same class and avoids any construction-order edge cases. Verified no dependency cycle:

HomeViewModel → RealtimeSyncManager → CloudSyncRepository → (no WatchHistoryRepository)
WatchHistoryRepository → Provider<RealtimeSyncManager>  (lazy, breaks construction)

Test plan

1. Sign in on two devices (both need ARVIO Cloud auth).
2. Start playing an episode on device A.
3. On device B, open Home and note the current resume position for that episode in Continue Watching.
4. Let device A play for 30+ seconds.
5. Within ~10 seconds of device A's next watch_history update, device B's Continue Watching row should refresh to show the new position without any manual action.
6. On device A, pause and watch the next 5-second watch_history update fire. Verify device A's own Continue Watching row does NOT flicker (self-echo skip).
7. Fully watch an episode to end on device A. Device B should move to the next episode within ~10 seconds.
8. Kill device B's app, bring it back — Continue Watching should still show the latest state (this path uses the account_sync_state channel, unchanged).

Risk

Medium. Changes touch the realtime sync core. Mitigations:

• The new realtime:watch_history channel is additive — if it fails, the existing realtime:account_sync channel still works and the 90-second periodic fallback still catches everything.
• The self-echo guard uses a tight 3-second window so local writes don't suppress legitimate events from other devices that happen to arrive at the same time.
• The event flow uses extraBufferCapacity = 4 on MutableSharedFlow so event delivery is non-suspending and can't back-pressure the network handler.
• No schema changes, no new Supabase tables, no migration. Uses the watch_history table that already exists and is already being written to on every device.